Copyright © All rights reserved micansinfotech.com
SOFTWARE: ASP.NET | VB.NET | C#.NET | RAZOR MVC 4 ASP.NET | RESTful Web services
The concept of awareness plays a pivotal role in research in Computer-Supported Cooperative Work. Recently, Software Engineering researchers interested in the collaborative nature of software development have explored the implications of this concept in the design of software development tools. A critical aspect of awareness is the associated coordinative work practices of displaying and monitoring actions. This aspect concerns how colleagues monitor one another’s actions to understand how these actions impact their own work and how they display their actions in such a way that others can easily monitor them while doing their own work. In this paper, we focus on an additional aspect of awareness: the identification of the social actors who should be monitored and the actors to whom their actions should be displayed. We address this aspect by presenting software developers’ work practices based on ethnographic data from three different software development teams. In addition, we illustrate how these work practices are influenced by different factors, including the organizational setting, the age of the project, and the software architecture. We discuss how our results are relevant for both CSCW and Software Engineering researchers.
For accountability purposes, all changes in the Alpha software need to be associated with a problem report . Among other pieces of information, a PR describes the changes in the code, the reason for the changes (bug fixing, enhancement, etc.), and who made the changes. An Alpha developer is delegated new tasks by being assigned to work with one or more PRs. These PRs are reported by other team members. Whoever is filling in the PR is responsible for filling in the field “how to repeat,” which describes the circumstances (data, tools, and their parameters) under which the problem appeared. When software developers report a PR, they also might divide a PR into multiple PRs that achieve the same goal. This division aims to facilitate the organization of the changes in the source code, separating PRs that affect the released Alpha tools from those PRs that affect tools or processes not yet released.
As mentioned in the previous section, each developer is assigned to one or more processes and tends to specialize in that process. A manager will follow this practice and assign developers to work on PRs that affect “their” respective processes. However, it is not unusual to find developers working in different processes.3 In this case, Alpha developers need to identify and contact the process owner to find out whether there is a problem in the process. 4 If there is a problem, developers will start working to find a solution to this problem. Even if the problem is straightforward, before committing their code, Alpha developers need to contact process owners to verify, through a code review (a prescription of the Alpha software development process), whether their changes in the process are going to impact the work of these process owners. Code reviews are performed by process leaders whose processes are affected by the changes in the PR. If the changes involve more than one process, a request for a code review has to be made to the owner of each process affected by those changes.
The need to contact process owners means that the developer working with the PR needs to identify the owner of the process being affected. This is not a problem for most developers, who have been working in the project for a couple of years and already know which developers work on which parts of the source code. In contrast, developers who recently joined the project face a different situation because they lack this knowledge. To handle this situation, newcomers use information available in the team’s mailing list. The software development process prescribes that software developers should send email to this list before integrating their changes in the shared repository. Developers thus associate the author of the emails describing the changes with the “process” where the changes were occurring: Alpha team members assume that if one developer repeatedly performed check-ins in a specific process, it was very likely that he or she was an expert on that process. Therefore, a developer needing help with that process would know who to contact for help
After having his or her changes approved by the process owner(s), a developer fills in the other fields of the PR, describing not only the changes made in the code (through the designNar field, for example), but also the impact these changes are going to have on the V&V staff.The information about the impact on the V&V staff is re- corded in two PR fields: (i) the “how-to-test-it” field is used by the test manager, who creates test matrices that will later be used by the testers during the regression testing; and (ii) another field that describes whether the Alpha manuals need updating. The documentation expert uses this information to find out whether the manuals need to be updated, based on the changes introduced by the PR. In some cases, developers are even more specific.
Ehrlich explains that “an expertise locator provides a valuable tool for individuals to develop awareness of ‘who knows what’ and to reach out to people across the organization.”Expertise networks are intended to cover organizational timeframes. Expertise networks cover careers and multiple projects. Expertise networks focus on general abilities. Expertise networks are enterprise wide. Expertise networks reflect the developing and maintaining of an information repository. Expertise networks require eliciting tacit knowledge and transcribing explicit information. Expertise networks prescribe new contacts or remaking old contacts.
Awareness is “an understanding of the activities of others, which provides a context for your own activity.” In the introduction to this present paper, we described an awareness network to be “the network of actors whose actions need to be monitored by an actor and those to whom this actor needs to make his or her own actions visible.” Awareness networks reflect the carrying out of a specific task. Awareness networks require displaying and monitoring one’s activities. Awareness networks emerge by observing coworkers’ Activities. Awareness networks exist in task and project timeframes. Awareness networks cover members in a team and one or a few projects. Awareness networks focus on specific activities. Awareness networks are team sized.
In the field of Computer-Supported Cooperative Work, the term awareness is used to describe a range of work practices by which social actors coordinate their work through (i) the display of their actions to their colleagues, and (ii) the monitoring of actions from their colleagues. Recently, this concept has been explored by software engineering researchers in the design of collaborative software development tools. Most empirical studies related to awareness focus on the identification of these coordinative practices and assume settings in which the social actors who display and monitor actions do not change often. However, the practices of displaying and monitoring actions associated with awareness are useful only to the extent that social actors know who they should monitor and to whom they should display their actions. In collocated settings, this information is intrinsic. However, there are settings where this information is not as clear, e.g., distributed software projects. Previous studies have largely overlooked the identification of these actors. Accordingly, this paper focuses on the software developers’ work practices necessary to identify the list of actors whose actions should be monitored and to whom actions should be displayed.
We call this set of actors the awareness network. In shifting the focus, it is possible to observe a myriad of such practices, how they are influenced by the work setting (organization, software architecture, etc), the problems that arise when this identification is problematic, and, finally, software developers’ concern with the management of these networks.We have drawn our results from empirical data from three software development teams that were observed and interviewed. Results of our analysis suggest that the awareness network of a software developer is fluid (it changes during the course of software development work) and is influenced by three main factors: the organizational setting (e.g., the reuse program in the BSC corporation), the software architecture, and, finally, the recency developers try to manage their awareness networks to be able to handle the impact of interdependent actions. These results can lead to important contributions for collaborative Software Engineering. For instance, collaborative tools (like Ariadne CollabCVS Fast- DASH Jazz and Palantír )and theoretical approaches (like socio-technical congruence ) that leverage software architecture to provide awareness haveprovided some promising results.
However, the problem with these approaches is that, in practice, the architecture is not fully disclosed to or fully understood by all developers.The fluidity of the awareness networks suggest that these same tools and approaches need to be flexible to easily adapt to a software developer’s current context, including task, and software process phase. Similarly, most approaches and tools do not properly describe the organizational context where they would be adequate leading to misinterpretation and generalization of results. Our results indicate that the ways people identify the colleagues that they need to be aware of is a necessary and integral aspect of collaborative work. Being aware, and identifying who one needs to be aware of, is a software developer’s ongoing achievement and needs to be properly studied and supported by software tools.